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BffiESOES TEST SVST04 FOR 

cckmunicatioks systpis ocnpofwce gafriwG 2203\ 

Bft^VTrtaund and Sunnary cf the Invention 

Ihe present invention relates generally to the testing of 
ccemmications svstan software. More specifically, the invention 
relates to a method of deteanininq whether a ooammications scheme 
eonfoxms to a specification of ccnnunicaticna protocol* such as the 
NAP specifi ca tio n , based on the Open 8ystens Model established by the 
International Organization for Standardization (ISO) . 

Many aanufacturing processes today are controlled by 
networked computer systems which sust eonounicate with one snother. 
In the interest of standardization, the automotive industry, and other 
aanufacturing industries, have proposed a specification of 
ccratunications protocols which are used to interconnect computer 
systems and robotic system to cenmanicate with one another. One such 
specification is the MAP specification. She MAP specification is 
based on a sodel of conputer connunication established by the ISO 
called the Open Systems Mndel. Ihe Open Systems Model (and the MAP 
specification) divides the connmications problem into seven sets of 
related issues cfl l lffl layers, which are di sn is sfrt below. 

To ensure compatibility with a SBnufacturer's existing 
computer and automation equipment, suppliers and vendors of new 
equipment sust develop compatible oomnunications software. The new 

« 

•quipDent oust c onfor m to the MAP specifica t io n . 

The MAP specification and the Open Systems Model vpaa which 
it is based are comparatively complex oamunicationa protocols. 
Itesting a new camunications program or a new piece of or nwimi e ating 
hardware to determine if it conforms with the MAP specification is not 



* single task. As explained sore fully below, in order to test all 
layers of a canrunications systsa far conformance it has heretofore 
baen necessary for the new product developer to write end include 
special test p ro gr a ms directly into the oonBunicationa software. This 
adds complexity and expens e to the software and can leave the 
conraunicatlons system with extra software baggage that is not needed 
once c onforman ce has been detemined. Possibly even sere troublesome 
is the fact that such test routines have heretofore been closely 
linked to a particular layer within the HAP specification. This close 
linking has Bade it very difficult to integrate certain functions 
be tween adjacent layers without the test routines getting in the way. 

The present invention overcomes this problem by a technique 
of nanipulation of upper layer flow control mechanisms in order to 
manage lower layer message transmission and reception for conformance 
testing purposes. The invention allows the new pr odu ct to be tested 
without the need to include some of the previously required special 
test functions in the new product software. The invention permits 
conformance testing to be effected without interfering between 
adjacent layers of the software being tested. Thus, the invention 
allows the communications software to employ integrated or 
interrelated adjacent layers, such as b e twe en the network and 
transpo rt layers in order to improve software performance. 

More specifically, the invention permits the protocol 
conformance testing to be performed on the network layer of the 
protocol implementation under test (IUT) , that is, the internet 
p r o toco l entity in the system under test, without altering or 
appending test code to the network/ transp ort interface (between the 
network and transpo r t layers) of the pro du c t . The invention 



^ndirecUy ■mages message flow between the netwarit/txeneport 
lnterf aoe of the product In artier to determine whether the network 
layer of the ismlementation under test ia passing date to and 
accepting data from the transport layer oorrectly. 9m invention 
perform the network layer protocol testing in a noninvasive faehion. 
Una invention controls the flow of information through toe transport 
layer, to thereby indirectly co ntro l the network service interface 
through the transport, by indirectly taking control over the credit 
and acknowledgment signals automatically and periodically generated bv 
the transport layer. 

For a sere complete understanding of the invention, its 
objects and advantages, reference nay be had to the following 
specification and to the accompanying drawings. 

Brief Description of the Drawings 

Figure 1 is a block diagram depicting the seven layered 
communications system protocol; 

Figure 2 is a schematic block diagram illustrating the 
physical communication topology inplemented by the presently preferred 
communications system; 

Figure 3 is a block diagram illustrating an intermediate 
system or router far transferring messages b etw een ncnad jaoent nodes; 

Figure 4 is a message sequence diagram illustrating a flow 
of message transmissions and ackncwledgmenta between initiator and 
recipient; 

Figure 5 is a diagram illustrating the window principle used 
by the transport layer of the otmamications system to regulate the 
flow of information; 



Figure 6 ii a block diagram of the test program of the 
Invention, illustrating the manner in which an examplary 
eonnunications system program ia tested; • 

Figure 7 is a diagram illustrating the form of protocol data 
units at each of the seven levels? and 

Figure 8 (8a and 8b) is a flow chart depicting the testing 

method of the invention. 

Description of the Pre ferred Embodiment 

Before a detailed explanation of the invention is given, a 
brief overview of the MAP specification will be presented. The HAP 
specification is described in, General Motors, •Manufacturing 
Automation Protocol Version 2.1," General Motors Corporation 1985. 
The MAP specification is based upon the Open Systems Interconnection 
(CGI) Model established by the ISO. A detailed explanation of the OSI 
Model may be found in ISO IS7498, "Information Systems Processing — 
Open Systems Interconnection — Basic Reference Model," 1984 which is 
i n co r porated herein by reference. 

Figure 1 diagranmatically illustrates the seven layers into 
Which the MAP ccnnunications protocol is divided. At the lowermost or 
most primitive level is the first level, the Physical Layer. The 
Physical Layer is responsible for encoding and physically transmitting 
messages between two adjacent nodes on the network. The MAP standard 
uses a bus topology pictured in Figure 2. The Physical Layer 
implements the IEEE 802.4 standard. Connunication is over a coaxial 
cable 10 which provides two camunications channels. One channel is a 
low frequency channel which propagates in a first direction and the 
other channel is a high frequency channel which propagates in the 



opposite direction. A head end unit 12 terminates one end of the 
^jble for shifting the low frequency camunications up to the high 
frequency to thereby change the propaqation direction. The 
ccranu nicatinq units 14 place eonrunications on coaxial cable 10 at the 
low frequency where they propagate to the head end unit 1?. for 
retransmission at the higher frequency. All com unicatinq units 
receive data at the high frequencv. 

Returning to Figure 1, immediately above the Physical Layer 
is level two, the Data Link Layer. The Data Link Layer is responsible 
for framing the binary data handled by the Physical Layer into octets 
(eight bits) . A plurality of octets are grouped into data packets hv 
the Data Link Layer. The Data Link Layer connects a link address to 
each packet which identifies which communicating unit 14 or node is to 
receive the packet of data. The Data Link Layer is responsible only 
for addressing data intended for physically connected devices on the 
coaxial cable. In order to send a message to a nonadiacent node (one 
which is not physically connected to the c oaxi a l cable) an 
Intermediate systems unit or router is employed. 

The third level, or Network Layer, handles the routing of 
information through intermediate systems or routers, The Network 
Layer establishes the protocol for transferring messages from a node 
on one cable to a node on a physically separate cable. Figure 3 
depicts an intermediate system or router 16 which interconnects a 
first c ommu nication system IB, which communicates over a coaxial 
cable 10, with a second communication system 20, which communicates 
over a fiber optic cable 22. The intermediate system or router 16 
employs two Physical Layers 24 and 26 which are compatible with the 
coaxial cable and fiber optic protocols, respectively. The Data Link 



vers 28. and 30 respond to the Physical Layers 24 and 26, 
respectively, and ii> turn oomnunicate with the Network. Layer 32 of the 
router. In effect, the network Layer 32 of the router can be 
considered as a bridge between the respective Network Layers of the 
first and second catmunications systems 18 and 20. In this fashion, 
it is possible to establish catmunications between two nonadiaeent 
nodes employing similar or dissimilar physical protocols. 

In theory, the Network Layer can determine the recipient 
node of a given comnunication by a variety of different schemes. One 
mchene is a connection oriented protocol in which a permanent virtual 
pipe is created between two devices. Using such a protocol, it is not 
necessary to place a signature on the message being conveyed, nor is 
it necessary to place anv routine, information on the message, as the 
permanent virtual pipe automatically describes the identity of both 
the initiator and the recipient. Another protocol is the 
connectionless oriented protocol. Hie connectionless oriented 
protocol requires that a message be enclosed in or accompanied by an 
address and a signature identifying the desired recipient of the 
message and also identifying the initiator of the message. The 
connectionless oriented protocol, unlike the connection oriented 
protocol, does not guaranty that messages are conveyed in anv 
particular order. Hie MAP specification presently adopts the 
connectionless protocol, This connectionless protocol is ccnnonly 
known as the Internet or IP protocol. 

Because the IP protocol does not guaranty that messages are 
received in the order in which they are sent, some provision must be 
made to ensure reliable delivery and servicing of messages. Referring 
back to Figure 1, the fourth level or Transport Layer provides this 



ssurance that messages are reliably delivered. The MAP specification 
uses a positive acknowledgment technique in which the recipient of a 
message acknowledges receipt by returning an acknowledge signal (ACK) 
to the initiator. The details of this acknowledgment system are 

explained below. 

The Transport Layer also handles message flow control. Flow 
control is the process used to ensure that the pace of comunications 
is appr opriate for the two connunicating devices. For example, if 
comnunication is to be established between a high speed mainframe 
computer and a low apeed personal computer, certain provisions must be 
made to establish a working connunication rate. This is done by a 
process of negotiation between the two connunicating units, and 
•pacifically between the Transport Layers of the two ceranunicating 
units. The two connunicating aystans agree in advance of 
communication on the maxinun message (or Protocol Data Unit, TOJ) 
size. As the exchange of messages proceeds, each connunicating unit 
can send control parameters to control the rate of PEC transmission. 

The mechanism by which the transmission rate is controlled 
is based on the PDU sequence number. A unique sequence identification 
number is attached to each WJ, ao that the sequence numbers can be 
used to place the packets in the proper order should they become 
nisordered. When camunication is established, each connunicating 
unit conveys to the other the sequence number corresponding to the 
maxima number of PDUs which it is prepared to receive. The exchange 
of data is full duplex, either side can send PDWs to the other up to 
the maximum sequence number given to it by the other. 

As a simple example, if both units are initiating 
camunication and unit A is prepared to receive three FWs, unit A 
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» Id send the mniber 3 to unit B. Thereafter, if unit A wishes three 
more PDUs to be sent, it would update the sequence nurcber to 6. Unit 
B could, at the same tine, establish its own desired rate of 
camunieation with unit A. Unit B could initially inform unit A that 
it is prepared to accept PDUs up to and including sequence number 10. 
After these ten are received, unit B could request another ten, by 
u pda ting the sequence number to 20, or it could slow the rate down or 
speed the rate up by selecting either a lower or a higher sequence 
number. The initial sequence nuntoers are established during a 
connection establishment phase of catrnunication. Thereafter, the 
sequence numbers are updated as part of the message received 
acknowledgment (ACK) signal which is relayed from recipient to 
initiator. 

To guard against system hang up which would occur if both 
camunicating units were waiting on the other to acknowledge, the 
Transport Layer entities in each unit are designed or required to 
routinely send redundant acknowledgment signals which convev the 
current allowable data messages which can be received. This allowance 
information is referred to as a window. 

For a more ccnplete understanding of the positive 
acknowledgment system implemented by MAP, refer to Figure 4 which 
illustrates an exemplary camunieation between an initiator and a 
recipient. It should be kept in mind that MAP iaplements a full 
duplex camunieation svstem, both ecnmunicating units can be 
initiators and recipients simultaneously. Referring now to Figure 4, 
two columns axe depicted, designated as initiator and recipient. In 
these columns are a sequence of message transmissions with arrows 
indicating the direction of transmission. Oonnunication begins with a 



^nection establishment sequence. The connection establishment 
portion of the ccnnunication is indicated generally at 40. The 
sequence begins as at .42 with the initiator sending • oonnection 
request (CR) to the recipient. The recipient responds by transmitting 
a connection confirmation message (OC). The initiator then 
acknowledges that it received the connection confirmation by •ending 
an acknowledgment (ACK) . Daring this connection establishment phase, 
both initiator and recipient specify the minimum and maximum sequence 
number which it is prepared to receive (i.e., the window). For 
purposes of illustration, only communications initiated by first unit 
and received by a second unit are illustrated. It will be understood 
that a similar diagram would result if the communications initiated by 
the second unit for reception by the first unit were to be 
illustrated. 

When the connection is first established, camunication is 
assumed to begin with sequence number 0 (the first message of 
transport user information) . The highest permissible sequence number 
established by the recipient, together with the initial ■equence 
number 0 establishes the number of messages which can be sent to the 
recipient. This number may be conveniently represented as a window 
illustrated in Figure 5 bounded between the last sequence request (in 
this case the initial sequence 0) and the highest permissible •equence 
number requested. If, for example, the recipient wishes to limit the 
reception to 100 messages, then the lower edge 44 of the window would 
initially rest at ■equence number 0 while the upper edge 46 would be 

at •equence 100. 

Returning to Figure 4, once the connection establishment 40 
has occurred, the initiator commences data trananission PDUs (DT). 



. jc purposes of illustration, it will be assured that the recipient 
has requested three messages (PCTJs) to be sent. Accordingly, the 
initiator transmits the first three messages corresponding to sequence 
nutters o, 1 and 2. This is indicated generally at 48. Hien the 
recipient receives the third sequence, it sends an acknowledgment 
signal (ACK) back to the initiator. This is indicated generally at 
50. The anknowledgnent signal contains the sequence nwnber of the 
highest sequence received, in this case message 2. Thus the initiator 
knows that the recipient has received all three packets. If desired, 
the recipient could, with its acknowledgment, change its window size 
by requesting an additional group of packets different fran the number 
originally requested. For example, the recipient may wish to allow 
the transmission of up to ten messages. In this case the recipient 
would revise its highest permissible sequence number to 13. If the 
recipient does not revise the highest permissible sequence number, 
then it remains at the earlier selected value, 3, and no further 
sequences can be transmitted. 

Assuming that more sequences have been requested, the 
initiator would continue to send messages, and would expect to receive 
acknowledgments thereafter. This is shown for messages 3 and 4 as at 
52. It is, of course, possible that a particular message mav not be 
received in the proper sequence. A given packet can become 
temporarily delayed or lost during transmission. At 54, the initiator 
sends messages 5 and 6. The recipient acknowledges only message 
miter 5 to illustrate the case in which message natfcer 6 is not 
sequentially received. Meanwhile, the initiator continues to send 
messages 7 and 8, as at 56. The recipient, however, cannot 
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-knowledge receipt of message nunbers 6, 7 and 8, since it has not 
yet acknowledged message number 5. 

In accordance with the standard operation of the Transport 
Layer protocol, the recipient is required to periodically send an 
acknowledgment reflecting the last sequence number which it has 
received. In this case, the recipient has received message nittoer 5. 
Accordingly, at step S3 the recipient sends a periodic acknowledgment 
of receipt of message number 5. The initiator determines from this 
acknowledgment that the recipient has not yet received message nixnber 
6 (which was sent earlier) at 54. Accordingly, the initiator resends 
message number 6, at 60 and the recipient then responds with an 
acknowledgment of message number 8. In this example, it is presumed 
that only message number 6 was not received by the recipient and that 
the message numbers 7 and 8 were received and were stored pending 
receipt of message number 5. 

It is important in understanding the invention to recognize 
that the window defined by the upper and lower edges illustrated in 
Figure 5 can change in sire with each acknowledgment. The lower 
window edge 44 represents the last sequence number acknowledged and 
the upper window edge represents the naxiaun sequence number 
permitted. The present invention is primarily concerned with 
controlling data flow between the level three Network Layer entities 
through use of level four Transport Layer mechanisms. For 

« 

completeness, a brief description of the level five, six and seven 
layers will be presented. 

The level five or Session Layer illustrated in Figure 1 is 
primarily involved in synchronising the cairounicating units to take 
turns in carrying out a conrounication. The Session Layer is roughly 



^logoua to sentence punctuation, which breaks one complete thought, 
allowing another message, possibly from the other unit to reply. 

The sixth level or Presentation Layer is responsible for 
handling the data representation between comunicating units. 
Oonnunieating units nay not comunicate using similar encoded 
languages or similar file types. The Presentation Layer provides an 
agreed upon canton language, encoding or file type by which the two 
incompatible systems may ccmnunicate. The Presentation Layer can also 
perform data encoding and decoding for data encryption and the like. 
Although the OSI Itoiel permits comunicatinq systems to 
negotiate protocol at this level, the presently implemented VKP 
specification does not employ such negotiation. 

The final and seventh level is the Application Layer. The 
Application Layer defines for certain contexts what language is to be 
used during ccnnunication. The context can be either implicit, based 
upon the nature of the ccmnunication or it can explicitly stated. The 
Application Layer is needed because data being canrunicated may be 
organized in fundamentally different ways by different computer 
systems. The Application Layer defines a mutually agreed upon wav in 
order to refer to things. One or both of the comunicating units may 
have to translate its data to the mutually agreed upon format if such 
format is not inherently provided. 

As stated above, the present invention is involved primarily 

* 

with testing the conformance of the level three Network Layer internet 
protocol entity of a system under test. The objective is to transmit 
both valid and invalid data to the Network Layer entity in order to 
de termin e whether it properly distinguishes between the two. Another 
objective is to cause the Network Layer to pass data up to the 
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,iransport Layer and also to receive data passed down from the 
•Transport Layer without error. The Network Layer is connectionless in 
that it does not implement connection-oriented protocols as sane of 
the upper layers do. Prior to this invention, in order to test the 
Network Layer, it has been necessary to place a special test program 
in the Transport Layer of the system under test (or at the 
network/Transport Layer interfacel for the purpose of •ending 
predefined test messages through the transport/network interface to 
the Network Laver in order to see if the Network Layer properly 
receives the same. The test program also mist respond to predefined 
test messages sent through the transport/network interface fron the 
Network Layer in order to determine whether the Network Layer uroperlv 
oonvevs messages. The addition of this test software adds to the 
complexity of the ecmWcation system and makes it difficult to 
design high performance software which may need to integrate certain 
closely related functions of the Transport and Network Layers. 

Hvdng thus presented a general overview of the invention 
and the presently preferred operating environment, a more detailed 
explanation of the embedded test system will now be given. 

The invention is referred to as the -embedded" test system 
or technique because the network service interface in the system under 
test is allowed to remain naturally coupled to the Transport Layer. 
The camon test method in which the network service interface is 
required to be Decoupled from the Transport Layer and . driven bv 
specialized software in the system under test is referred to as the 
■exposed" test system or technique. 

The invention utilizes as its implementation base the 
software which was developed to perform the exposed test technique. 



- 13 - 



114- 

^urthermre, the invention is capable of executing the sane set of 
teat cases as the exposed test systan. The choice of technixjue Is 
left to the designer of the system under teat. In other wards, the 
"sBfeedded" test system uses the existing "exposed" Internet test 
system software es its Jsplementation base. In fact, only one test 
system is maintained, with a user ooranand to select wjether an 
embedded or an exposed service control i» available. 

The exposed version continues to use the HBS defined Test 
Management Protocol Data Units (TMPttJl end the associated Upper Tester 
for control of the IOT service interface. A description of the TM 
(test nanagement) Protocol can be found in SST/afc-85-7, National 
Bureau of Standards, The Design of a Teat System for nplementations 
of ISO Connectionless Network Protocol," July 1985 (NBS 86). 

Figure 8 illustrates .the presently preferred netted of 
inplementing the embedded test system emoloying the invention. The 
sequence starts at step 100 and proceeds to set up the connection 
oriented communication between the test system software and the system 
under test at 102. The remainder of the test sequence illustrated in 
the flow chart of Figure 8 comprises a plurality of branch points (at 
at 104, 110, 120, 122, 128, 136 and 144) where .pacific tests can be 
per footed. 

For example, if it is desired to test the internet protocol 
(IP) data transmitter, flow branches at 104 to execute steps 106 end 
108. m step 106 a predefined unit of data, referred to es an NSCC, 
containing an XKTPDO is sent with a credit one greater than the 
previous sequence number. This opens the credit window to allow one 
nessage unit to be returned from the system under test. In 
isplementing these tests the system under test would normally be 
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.^conditioned to aend and expect to twive a large nutter of octets 
of data, ly opening the credit window with a credit one greater than 
the previous sequence, one of the plurality of data octet* la 
permi tted to flow from the system under test to the test system. At 
step 108, the test system sets a flag to expect to receive a WTO 
with a sequence one greater than the previous. 

If it is desired to test the IP data receiver, step 110 
branches control to step 112 which sends an HSDO containing a DTWW 
with a sequence number one greater than the previous. A decision has 
been made at step 114 whether to corrupt the IPOOs which carry the 
IEDU. If corrupted, a flag is set to tell the test system to expect 
an error message ERJEFDU or no response. If -the data is not 
corrupted, e flag is set to tell the test system to expect an 
scknowledgraent message AKJHTO with a sequence number one greater than 
the previous. 

As explained above, the map ecnrainications protocol requires 
periodic sending of duplicate acknowledgment signals to guard against 
system hang up. Shese duplicate acknowledgment signals are 
intercepted et branch point 120. If a duplicate acknowledgment signal 
is received, no action is taken by the test system and flow control 
siaply returns to the top of the loop. 

In order to test whether the acknowledgment sequence flagged 
in step 18 is received, step 122 monitors receipt of the expected 
acknwledgment and branches to step 124 if the acknowledgment is 
received. Step 124 tests the acknowledgment to see if it was in 
response to the transmitter test end if so no -fault is reported, 
otherwise s fault is ivyovtr6 at 126. 
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A similar test ia performed at step 128 to determine if the 
DT WDO flagged at atep 108 has been received. If ao, atep 130 tests 
to determine whether this was in response to a receiver teat. If ao, 
an acknowledgment signal AKJRWJ is sent at 132. Otherviee a fault 
condition ia aignaled at 134. 

In a aimilar fashion at atep 136 a test is performed to 
determine whether the expected error message flagged in atep 116 ia 
received. If ao, a determination ia made as to whether this error 
aignal ERXFDU is in response to a receiver test. If ao, a duplicate 
DT TPDCJ is sent. Otherwiae a fault condition ia aignaled at 142. 

Finally, if any other non-OT or non-Bl IPECs are received or 
if any incompletely reassembled DTDTOs are received co ntr ol branches 
at 144 to aignal a fault at 146. At 148 a decision ia made whether to 
terminate the testing or whether to return to the top of the loop for 
further testing. If testing terminates, the connection is broken at 
150 whereupon the test program ends at 152. 

•The embedded version uses standard Transport Protocol Data 
Units (TPDU) and a MAP 2.1 conforming Transport ftitity for IOT network 
service interface control. The IOT Transport Bitity ia, in turn, 
controlled by the Remote Scenario Interpreter as used in Transport 
testing. Only one transport scenario (test case) is required for use 
in e mbedded IP testing. Thus no direct access to the IOT's network 
service interface is required. 

Controlled use of KAP/ISO Class 4 Transport Protocol in 
embedded testing provides the same functionality for controlling and 
observing Network Service interface activity as the custom protocol 
required in the exposed method. (There are minor exceptions, but the 
lost TM functionality is unnecessary to begin with.) During internet 
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otoool (IP) Test Case execution, only WJfKJi and AKjBTOs axe 
car ried in the IPDU data portions. Transport eormectian establishment 
anl termination are carried on outside the execution of. any IP Test 
Case. 

Connection establishment is initiated through issuance of a 
■connect" conraand. A CR-CC-AK TPDU exchanged is expected. The test 
system continues to transmit CRs for a reasonable tine before giving 
up. IP Test Cases only execute if a connection is deemed open. 

Transport timer and parameter values are established through 
CR-CC negotiation, or predefined in the embedded IP Test Plan. These 
are e agaected to be similar to values used in current transport 
protocol conformance tests. 

Valid XFDUs data sent by the Lower Tester are correctly 
sequenced DT_TPDUs with data format observing the Remote Swmarin 
Interpreter expectations. The Remote Scenario Interpreter (RSI) is 
the same as used in standard transport protocol testing. IPDCJ data 
sent in invalid IPDUs is also sent as correctly sequenced DTTPDUs. 
If the invalid IPDU is accepted, then the test system signals a fault. 
If a co r rec t error response is returned, then the testing continues as 
passing. In order to maintain corr e ct transport message sequencing, 
the DTTPDU will be retransmitted in a valid IPDU after the correct 
error response is received. 

An AK TPDU with correctly increased lower window edge is 
expected in response to a DTTPDU carried in a valid IPDU. 

In order to restrict the IUT Transport entity from 
prematurely •ending DTTPDUs, AKTPDUs sent by the test system supply 
no cr edi t, then an NSDU (Network Service Data Unit, i.e., e correctly 
sequenced DTTPDU) from the IUT is desired, an AKTOXJ granting one 
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' -edit is sent by the Lower Tester. If the Lower Vertex receives a 
valid >EDU (i.e., a valid OTJBW) the window is reclosed and the 
DTTFDU acknowledged. Oils MCJBCO granting credit does not specify 
NSDU mite. Such a specification aeons to be wjflesirabla, since it 
would attempt to con tro l an implementation apecific parameter, thus 
for conformance testing purposes, the AX with credit is sufficient. 
Note that the mjBOO data from the IOT is expected to follow correct 
Remote Scenario Interpreter format. 

Both the Lower Tester and the IOT are required to 
per iodical ly transmit an AKTPDU to satisfy the Transport window time 
requirement. This enables both parties to be cognizant of each 
other's continued viability. 
Bibedded Service Control and Observations 

The exposed mode system uses a conformance entry to keep 
track of all expected XPDU from the IOT. This table is appropriately 
filled upon the test system sending an DTO, and the table entry is 
removed upon r ec ept ion of satisfying IPDO. 

In anbedded mode, this table is not used in connect and 
disconnect processes. Per cormect/disconnect processes only the 
transport connection context data structure is consulted. 

During IP test case execution, both the conformance table 
entries and transport context is used. Since only DrJHOJs and 
JKTFDUs are used during IP test case execution, this is 
straightforward. The test system uses the following rules: 
1. W TITO is received: if the DT is in sequence, it is in the open 
window, the data portion is correctly formatted, and a 
conformance entry generated by an WJHTO with credit has been 



- 18 - 



sent, then the entry is reaolved, the Tctx- ia updated, and an 
JWWDU ia aent by the Lower Tester. 
. AKTO with duplicate seq* is received: update the Ttetx" in an 

appro p r iate nanner. 
. «TO with greater aeql ia received: if a -Valid Data 
TO"-type conformance entry exiata and an outetanding DTTO 
haa been tranamitted, then the entry ia resolved, and the Tctx" 
ia updated. 

DTTO within valid data TO ia sent: a good OTTO ia to be 
«ent of size n octeta of data according to the Teat Case, h 
•Valid Data IPDU"-tvpe conformance entry ia generated, and the 
XFQU ia aent. 

5. DTTO within invalid data TO is aent: a bad OTTO is to be 
aent carrying n octets of data, and error report flag is aet on, 
as according to the Itest Caae. A "Valid Data TO"-type 
conformance entry is generated, and the TO is aent. 

6. sno with duplicate aeql is aent: the Tctx" indicates that 
the window timer has expired. 

7. WTO with duplicate aeqi and credit ia aent: an WKJ carrying 
a correctly sequenced DTTO is expected. X ccrtoance entry 
is made end the data IPDU with AKTEOJ is aent. 

8. AKjnCTJ with greater aeq# is aent: a -Valid Data TO" entry has 
been resolved and a data HDD ia sent. 

9. ERJTO is received: if "Error-TO" conformance entry exiets, 
then the entry ia resolved. 

Integration with Current Internet Software: 

The embedded test functionality is integrated with the 
existing software in manner such that the changes are isolated and 



o o 

ciearly stru ct u red. An overview of the eac p oe ed system eoftware 
structure la presented, followed by the changes nade to support the 

embedded system. 

The exposed eystem eoftware is structured as e continually 
looping process. The nodifieations/alteretlons to support the 
embedded system work within this structure, the following peuedn-code 
describes the dual-mode system. Statements Which are additions are 
Barked "*A"» modifications are narked "*M." 

forever 
I 

if (ccmmand from user terminal) 
*M execute command; 

*A if (embedded mode) 
*A 

*A send connection maintenance TOXJs; 

•A send AKs to confirm valid DTs; 

if (test case has been queued ft& no test case in-progress) 

seed test case; 
•M build abstract XFDUs' 

queue abstract IPDDs far transformation; 
*M set up conformance entries for receiving; 

tes t case is considered in-progress; 
if (abstract ZFOJs are queued) 

transform abstract IPDUs into concret e HDUs* 

queue con c r et e IPDUs for sending; 
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if (concrete ZFDUb are queued) 

•and concrete IPOUs; 
if (incoming XFCUi are in receive queue) 

validate TTOU header; 
*M check data and reassemble; 

•H evaluate con fo rmance to test case; 

if (test case timer event) 

take appropr iate action; 
if (test in p rogress tt all conformance entries resolved) 

test is finished; 



Modifications to s upport the efflhwWrt system are as follows: 

1. The global data structure Ittx' provides necessary data to 
support operation of the Transport connection. This includes the 
variables needed to generate and analyze data for the Remote 
Scenario Interpreter. 

2. The XPDU data generated at abstract IPDO formation tine is 
provided by a function named genjSatat). This function is 
apdified to generate appropriate DTTEOUa in embedded wade. 
Minor modifications to the conformance entry-making logic are 
required. 

3. UTOs are generated to request the IDT to send data. The data 
portion of such IFOUs carries "Send-NSCO" TWTOs in exposed mode. 
These TMFDUs are generated at abstract XFTO formation time by the 
function ■nsdujSataO." This function is modified for a nfrartlftd 
mode to generate XKTSDUs with credit (s) . Minor modifications to 
the conformance entry-making logic are required. 
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Raceived HWJb have their data portions analyzed by several 
different routines in exposed node. lhese routines switched to 
depending upon whether the data was identified to be a WPCC,.or 
just sequenced data. Ihese routines are called from either the 
"receiver ()" or "reassenbler 0 " function. 

5. in embedded node, only a single routine naraed "scandataO" is 
called, This routine is called from within "reassenbler 0 ." All 
IPDU data portions are passed through to "reassenbler 0" whether 
reassembly is required or not (this is the existing practice for 
exposed sole also), the •scan_data(P routine is modified to 
apply transport PDU type analysis. Received DTs are expected to 
be within the allowable window. Received AKs ere expected to 
acknowledge only outstanding DTs, or be duplicates for the 
purposes of connection maintenance. The "scandataO" function 
returns a count of errors detected and "reassenbler 0 " prints a 
message indicating either encoding or - length violations. 

6. transport connection is managed by the routine "transportO ." 
Ibis routine is called in the forever loop after the user catmand 
processing has been called. User connect, disconnect, and close 
ccmnands (if valid) set Tctx" variables indicating that a 
desired service be achieved, the ■transportO" routine sends any 
required concrete IPDUs directly. Received IPttJs are handled by 
■scandataO" within "reassenbler 0 "scandataO" bases 
its checking vpon the indicators in *1ctx." 

Conformance Analysis: 

Ihe existing conformance analysis ■echanijm is used nearly 
modified for embedded mode. Ihe changes are (1) the sequence number 
variable in each conformance entry is adjusted to correlate with the 
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^anspart PDU activity; and (2) an entry may require sore than one 
response to be resolved. This implies that any existing bugs to the 
conformance analysis mechanism still have not been connected. 

Transport level errors are an no u nced by error messages to 
the operator console. It is the operator who oust decide *wth*r such 
an error message indicates inconsequential activity, non-testability, 
or conformance failure, 
trans p o rt Connection Usage i 

The transport connection ie always initiated by the test 
system. The LT proposes low-bids on most negotiations, giving the IOT 
no choice. These bids are: checksum on, normal format, end no 
expedited data. The maxiitun TPDU size is proposed to be 512 octets. 

This size value is chosen to etitfort the current hardware 
limita tion s of the test system.. The TOT may negotiate this down. 
Regardless of the negotiated maximm size, the test system never sends 
an TPCV greater than the maxiiaan message size in the test system 

(currently 600 octets) . The current eet of IP Test Cases dees not 
require that an NSDU larger than 512 octets be sent or received by the 

test system. The test system also initiates the disconnect %men 

commanded by the console. 

Every transmitted AX carries the flow eontrol-conf irmation 

(fee) parameter. Reception of naked (parameterless) AKs result in a 

retransmission of the latest AK. 

Date Structures: 

The following data structure is used to maintain the 

tran spor t context: 
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lnt state; 
int TCref ; 
lnt RTref; 
lnt sizebid; 
int sendjKq; 
int send_ssq; 
lnt send cdtj 
lnt xecvseqs 
int racvjwq; 
lnt rsev odt; 
lnt windcwjfcime; 
int inact_time; 
int giveupjtime; 
int retran_time ; 
lnt retranjoount; 
lnt cr lenT 
lnt ak~ien; 
lnt dt"hlen; 
lnt dtjtlen; 
lnt dr~len; 
lnt dc~len; 
lnt ip~hlen; 
lnt ip~dui; 
unsigned 

char crpdur512]; 
unsigned 

char akpdul512b 
unsigned 

char dtpdut512] i 
unsigned 

char drpduI512] ; 
unsigned 

char dcpduT512] ; 

unsigned 

char lppdu[700] j 

long send_eount; 

long sendjgoal; 

long recvjBOuntj 

long recvjgoal; 

lnt akstat; 

lnt send dtseq; 

int sendjakseq; 

lnt sendjsot; 

int recveot; 

int timebase; 

lnt tend tine; 

int recvjtime; 

lnt send~vector; 

lnt reason; 

lnt dest; 



/* major state */ 

/* l/T reference number */ 

/* IOT reference number */ 

/* maximum negotiated tpdu size */ 

/* sending s«l»f*nrw number */ 

/* sendinq subsequence nunber */ 

/* sendinq credit */ 

/* receiving sequence number */ 

/* receiving subsequence number */ 

/* receiving credit */ 

/* vindow timer value */ 

/* inactivity timer value */ 

/• giveup timer value */ 

/* retransmission timer value */ 

/* retransmission count */ 

/* ex pdu length */ 

/* ak pdu length */ 

/* dt pdu header length */ 

/* dt pdu total length */ 

/* dr pdu length V 

/* dc pdu length */ 

/* ipdu header length •/ 

/* next dui to use */ 

/* cr tpdu for sending */ 

/* ak tpdu for sending •/ 

/* dt tpdu for sending */ 

/* ^ t pd u for sending */ 

/* dc tpdu for sending */ 

/* data ipdu for sending */ 

/* count of tran sport data sent */ 

/* total amount of data to be sent */ 

/* count of transport data received */ 

/* total amount of data to be received */ 

/* classification of ak type */ 

/* sequence number of last dt sent */ 

/* sequence number of last ak sent */ 

/* eot sent */ 

/* eot received */ 

/* tine at program initialization */ 

/* tine last data transmitted */ 

/* time last data received */ 

/* vector indicating next pdu to send •/ 

/• disconnect reason */ 

/* out-of-context pdu dest */ 
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«t «rci /* out-of-oontext pdu src •/ 

int TCsent roll; /* count of dt sent sequence nunber rollover •/ 

int TCack roll? /* count of ak sent sequence lumber rollover V 

int RTsent roll? /* count of dt recv •equence nunber rollover */ 

int KTacJc roll; /* count of ak recv sequence nunber rollover */ 

char * fault; /* pointer to pdu error */ 

DERBG DTregflOj t /* registers to buffer sent, but unacked dts */ 
struct 

jkpdu *pduptr; /* pointer to received pdu */ 

Connection Maintenance: 

Transport TPDOa are fumed for sending for 1a» purposes. 
They are either required to form the 1PDU data portion defined by an 
IP Teat Case , or they are required to set up, maintain or terminate a 
tran sp or t co n nection. 

The TPDOs used for IP Test Case support are generated at 
abstract IPDU formation time. Construction of these TPDOs (only DTs 
or AKs) reference the "Tctx" structure for appropriate values. 

TPDOs sent for connection maintenance are sent directly (the 
normal Bending queues are bypassed). These TPDOs are sent after 
console eotmand processing. The IPDO header is predefined with the 
DO! (data unit identifier), segment length indicator, total length 
i ndi cator and header checksum appropriately modified. All this 
information is found in the "Tctx." DUI values start at (decimal) 
1,000 so as not to conflict with IP Test Case DDIs. IP Test Cases 
sust refrain from specifying IPDUs with DOT values greater than 1,000 
to avoid potential conflict. Since all current IP Test Cases use DDIs 
beginning at (decimal) 1 (or for inactive subset tests no DUI at all) . 
IPDOs used for c ontr ol are easily distinguishable from UDOs under 
test. 
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All received IPDUs (both modes) are accessed through the 
•scandataO" function. In exposed mode, the TPOJ and its data are 
evaluated during reassembly, and a data structure named •eegmt," of 
type •REAWSBG,* is created to maintain pertinent inf conation about 
the segment. The buffer holding the actual segment is then released. 
Via reassembly process maintains a linked 'list of •eegmf structures 
for use in reassembly. 

The data type "REASMSBG" is modified to support embedded 
mode by maintain ing additional information relevant to TPDUs. This 
Includes partially reassembled IPDUs. If the IPDU data is valid 
according to transport protocol rules and Scenario Interpreter goals, 
then only the conformance entry need be satisfied. This entry is 
satisfied if the sequence number of the incoming DT or AK correlates 
to that of the conformance entry. 

Duplicate incoming AKs simply reset the inactivity time and 
are discarded. If the duplicate is •naked," a flag is set in "Tctx" 
indicating that an AK is to be transmitted. All transmitted AKs 
contain the fee parameter. All other out-of-sequence CTs and AKs are 
identified as errors. 

Transmission of TPDU is triggered by flags being set in 
Tctac.- In the main loop, immediately after checking for console 
ccanands, the function -transport ()■ is called. If flags are set, 
then an appropri ate IPDU is sent. The mechanism is used for tending 

« 

all TPDUs except for those DTs and AKs which are required as IPDU data 
during an IP Test Case. 

Template TPDUs are maintained in the Tctx" structure, ftach 
a TPDU is copied into a buffer containing an IPDU header, and the 
appropr iate parameters are modified in the IPDU header and the TRW. 
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2.7 

buffer is then passed to the device write routine, bypassing the 
queue structure used for IPDOs generated by the IP Test Cases. 

The "tranaportO" routine sends TKXJs needed to support a 
user earmand (connect, close, disconnect), MC a valid OT and close a 
windcw (which previously was permitted by an IP Test Case generated 
MO , and to satisfy standard transport timers. 
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C L AIMS 



1. A method of tasting the conformance of an 
inplmentaticn of an Internet protocol within a system under test to 
its specification, comprising: 

using the flow control and acknowledgment mechanisms of 
transport protocol to control the Internet (IP) protocol entity in the 
system under test. 

2. The method of Claim 1 wherein said flow control snd 
actaovledgraent sechaniams are used to maintain a controlled test 
environments . 

3. The method of Claim 1 wherein said flow control 
mechanisms specify the amount of messages expected to be transmitted 
by the internet pr ot ocol entity in the system under test. 

4. The method of Claim 1 wherein said acknowledgment 
amchanism is used to determine whether the internet protoool entity in 
the system under test cor rec t ly receives and delivers data to a higher 
user level in the system under test. 

5. The method of Claim 1 wherein said flow control 
nechanim is used to define'a window for allowable transmissions in 
the internet protocol entity in the system under test. 
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6. A sethod of testing -the conformance of an 
i^l«entation of an Internet protoool within a mtn under te.t to 
iti specification, carprising: 

wing the flow control aaehanian of transport protocol to 
control the internet tJP) protocol entity in the system under test. 

7. x wBthod of testing the conformance of an 
inplamentation of an internet protocol within a system under test to 
its specification, comprising: 

using the acknowledgment sechanism of transport protocol to 
control the internet (IP) protocol entity in the system under test. 

8. A method of testing the conformance of an 
implementation of an internet protocol, such method being 
substantially as hereinbefore described with reference to 
the accompanying drawings. 
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